
COPY OF ROPERS 
ORIGINALLY FILED 



orm^'s Docket No.: 774P010140-US(PAR) 



0 

03 ^c) 



PATENT 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



AppUcant(s): ROMANO-CRITCHLEY et aL Group No.: 

Serial No.: 10/052,602 

FUed: 1/18/02 Examiner: 
For: A UNIVERSAL SOFTWARE APPLICATION 



Commissioner of Patents 
Washington, D.C 20231 

TRANSMITTAL OF CERTIFIED COPY 

Attached please find tlie certified copy of the foreign application from which priority is claimed for 
this case: 



Country : Europe 

Application Number : 01300459.3 
Filing Date : January 19, 2001 

WARNING', "When a document that is required by statute to be certified must be filed, a copy, including a 
photocopy or facsimile transmission of the certificatidb s not acceptable." 37 CFR 1.4(f) (emphasis added.) 



Reg. No. 44,004 
TcLNo.: (203)259-1800 
Customer No.: 2512 




SIGNA 

Geza 



ATTO 




Type or print name of attorney 
Perman & Green> LLP 
P.O. Address 

425 Post Road. Fairfield. CT 06430 



NOTE: The claim to priority need be in no special form and may be made by the attorney or agent if the foreign 
application is ref erred to in the oath or declaration as required by S 1-63. 

CERTIFICATE OF MAILING/TRANSMISSION (37 CFR 1.8a) 

I hereby certify that this correspondence is, on the date shown below, being: 



MAILING 

deposited with the United States Postal 
Service with sufficient postage as first class 
mail in an envelope addressed to the 
Commissioner of Patents, 
Washington, D C. 20231 



FACSIMILE 

^ transmitted by facsimile to the 
Patent Office 



Date: b2 



3 3- 




Signature 

(type or pnnt name of person certitying) 



(Transmittal of Certified Copy [5-4] 



THIS PAGE BLANK (uspto) 



I; 



Europaisches 
Patentamt 



European 
Patent Office 




Bescheinigung Certificate 



Office europten 
des brevets 



Attestation 



Die ar^hefteten Unterla- 
gen stimmen mit der 
ursprQnglich eingereichten 
Fassung der auf dem nSch- 
sten Blatt bezeichneten 
europdischen Patentanmel- 
dung Qberein. 



The attached documents 
are exact copies of the 
European patent application 
described on the following 
page, as originally filed. 



Les documents fix6s d 
cette attestation sont 
conformes d la version 
initialement d6pos6e de 
la demande de brevet 
europ6en sp6cifi6e d la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n*^ 

01300459.3 



Der President des EuropSischen Patentamts; 
Im Auftrag 

For tne President of the European Patent Office 
Le Pr^ident de rOffioe europ6en des breveb 

P.O. 

RCvanbiJk 



DEN H&A6,D£N 

THE HAGUE, 23/01/02 

L& H&YE.LE 



B>A/EPCVOEB R)rm 1014 - 02:91 




THIS PAGE BLANK (usPTO) 





Europdisches 
Patentamt 



European 
Patent Office 



Office europ^en 
des brevets 



Biatt 2 der Bescheinigung 
Sheet 2 of the certificate 
Page 2 de rattestation 



Anmeldung Nr.: 
Application no.: 
Dsniande n*: 



01300459.3 




Date or filing: 
Datede<S6pdt: 




Anmelder 

Applicant(s}: 

Oemandeur(s): 

ThInMngcap Technology Limited 
London, El 6EX 
UNITED KINGDOM 



Bezeichnung der Erfindung: 
Title of the invention: 
Titre de f invention: 

A universal software application 



In Anspruch genommene Prioriat(en) / Prionty<ies) claimed / Priontd(s) revendiquee(s) 

Staat: Tag: Aktenzeiclen: 

State: Date: File no. ■ 

Pays: Date: Numero de depot: 



Internationale Patentldassifikation: 
International Patent classification: 
Qassification Internationale des brevets: 

GD6F9/44 



Am Anmeldetag benannte Vertragstaaten: 

Contracting states designated at date of filing: AT/BEA:ha:y/DE/DK/E5/FI/FIVGB/GME/1T/IJ/LU^MC^ 
Bats oontraetants ddsignds tors du depdt: 



Bemerlcungen: 

Remarks: 

Remarques: 



EPA/EPO/OEB Form 1012 . n.OO 



THIS PAGE BLANK OWTO) 



f. 



h 



V 



1 

A DNXVERSAL SOFTWARE APPLICATION 
Field of the Invention 

The present invention relates to the development and 
5 execution of applications software, and in particular, to 
the use of business modelling techniques in the development 
and execution of applications software. 

Background to the Invention 

10 Conventional software applications in use in business 

today have major shortcomings, these being high development 
costs, poor maintainability, integration euid comprehension 
difficulties. 

Most businesses experience problems in changing 

15 business applications, developing new applications, 
integrating legacy applications and incorporating new 
technologies, such as the Internet. There are three 
standard approaches to these problems: developing the 
applications in- house ; buying-off- the -shelf software 

20 products; and using software components. % 
These approaches have significant draw-backs in 
common: high failure rates; cost and time over-runs; a 
poor fit to business requirements; and a lack of 
flexibility in the face of business change. The resulting 

25 products are complex and relatively rigid, requiring 
significant consultancy effort for implementation. 

In current business applications there is generally an 
intermixing of business semantic and technology, 
infrastructure code. Furthermore, the business semantic 

30 code is poorly structured. This makes existing business 
applications relatively amorphous bodies of very con5)lex 
code. They are hard to comprehend and this poor 
conprehensive ability leads to poor understanding of the 
business application. This in turn leads to higher costs, 

35 higher risk of failure cmd other technology issues. In 
other words, something that Ccuinot be understood cannot be 
managed. 
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Thus, for ekaiiple, moaellihg of businesses using 
object orientated techniques typically involves defining 
the business as a number- of related objects. Each object 
is capable of responding to events to provide an action 
5 response. Accordingly, the object ties together both the 

semantics and the implementation of the business, as i 
described above. This can cause particular problems should / 
for example the implementation of the business change, as \ 
this can require the reformulation of the entire business 
10 model, including both the semantic and technology 

infrastructvtre aspects, to take the modified behaviour into f: 
account. 

Attempts to model businesses to overcome these 
problems have to date focussed on providing an underlying ; 
15 structure to the business data which models the business. 

This ip typically achieved by storing the bxisiness data in i 
a relational database, with the business model being ^ 
defined implicitly within the database schema, the schema , 
being ea^ressed as the meta-data of the relational ^ 

20 database. '\ 
Separately it is necessary to define an ^application 
which can interact with the database to implement the 
inplied business models and the associated functionality. 
The business model is therefore also implicit within the 

25 code base of the application, as well as within the 

database . [ 

As a result, alterations to the business model 
in?>licit in either the database or the application will not 
automatically be propagated to the application or the 

30 database, as required. Thus, for exanple. if the database |, 
schema is adjusted to modify the implied business model, 
then it will be necessary to make separate adjustments to 
the application code base. 

Accordingly, these techniques suffer from the drawback 

35 that the business models in5>licit within the database 
schema and the application code base are static and cannot 
readily be adapted to alternative business situations. The 



resulting business model is therefore brittle in the sense 
that once the schema , or application code base have 
initially been defined, they cannot practically be adjusted 
to allow . alterations in the way in which the business 
operates to be implementedi without having to manually 
propagate the impact o£ the evolution to the application 
code base or the database schema. 

As a result, business models determined in this way 
are typically unable to cope with alterations to the way 
which the business should function. 

Summary of the Invention 

According to a first aspect of the present invention, 
a computer program product con?)rises computer executable 
instructions defining a model execution application, the 
model execution application implementing a meta-model which 
is adapted to be populated with user inputs to generate one 
or more models, the meta-model being structured as a number 
of concepts, each concept having a number of properties, 
and one or more relationships between the properties of one 
or more of the concepts, wherein the relatioini^hips are 
defined as a concept within the meta-model. 

Preferably, the meta-model includes an active concept 
which can be populated with software components. In a 
preferred example, the meta-model comprises what is termed 
an "Exe" concept that defines processes that a model 
includes. In this context, an Exe. concept. defines any form 
of executable procedure. 

Preferably, the model execution application comprises a 
computer program code portion that provides access to the 
meta-model and which is adapted to accept user inputs to 
allow a model to be generated. In this manner, a user can 
populate the meta-model with data (including, where 
necessary, specialist software components) to generate a 
new model. 

The present invention therefore provides a conputer 
program which uses a meta-model to define: models, such as 
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business models. The meta-inbdel of the present invention 
defines the concepts and relationships of a model as a 
number of related instances within the meta-model. Since 
the meta-model is itself a model, it too is defined in 
terms of concepts and relationships which are instances 
within the meta-model, such that the meta-model describes 
itself. If a model needs to be adjusted, this can easily 
be achieved by modifying the instances of concepts and 
relationships within the meta-model, thereby ensuring that 
a self-consistent model is produced; These changes will 
then automatically be reflected in the defined model, 
thereby ensuring that models defined in accordance with the 
present invention can be easily adjusted. 

Preferably, the model execution application comprises 
15 a program code portion that provides access to models 
generated using the ^meta -model so that the models can be 
executed by one or more users . Preferably, this includes 
populating the models with data. 

Preferably, the model execution application con?)rises 
20 an infrastructure model defined in terms of the meta-model, 
that facilitates the execution of the meta-model and any 
models generated using the meta-model . 

Preferably, the infrastructure model is adapted to 
accept user defined implementation inputs to populate the 

25 infrastructure model. 

Accordingly, when installing the model execution 
application on a computer system, the infrastructure model 
preferably presents a user interface that allows the meta- 
model to be installed and executed by a user. Typically 

30 this would be carried out by a systems administrator. 
Thereafter, a systems analyst and/or a systems developer 
can run the application to generate new models which, for 
example, represent one or more business domain models. 
These can then be implemented by returning to the 

.35 infrastructure model and populating the infrastructure 
model further with implementation data associated with the 
new business domain models. These business domain models 
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can then be executed by users to implement the business, or 
at least a part thereof • 

According to a second aspect of the present invention, 
a computer inplemented method of generating a software 
application comprises the steps of: 

populating a meta-model with data to define a model; 

asspciating said model with a predefined 
. infrastructure model by populating the infrastructure model 
with implementation data associated with , said model so as 
to define an executable specific software application. 

According to a third aspect of the present invention, 
a coTt5)Uter program product comprises conputer executcd^le 
code for building software applications, the computer 
program including a model execution application 
implementing a meta-model that is adapted to be populated 
with user inputs to generate one or more models, the model 
execution application also including a predefined 
infrastructure model, the program being adapted to: 

populate the meta-model with data input by a user to 
generate a model; and, 

associate, said model. with the. predefined 
infrastructure model by populating the infrastructure model 
with implementation data associated with said model input 
by a user so as to define an executable specific software 
application. 

According to a fourth aspect of the present invention, 
a computer implemented method of executing a business 
domain model, the business domain model modelling the 
semantics of the business domain and being defined in terms 
of a meta-model, the method comprising the step of 
associating the business domain model with cin 
infrastructure model, the infrastructure model being 
defined in terms of the meta-model, to. define an executable 
specific software application, in which the infrastructure 
model is populated with implementation data associated with 
the business domain model. ' 



According to a fifth aspect of the present invention, 
a method of tnodelling a business domain comprises the steps 

dividing the business domain into a number of core 
concepts, each core, concept, having a number of properties 
and representing a self contained function of the business 

domain; 

determining the relationships between , the core 

concepts; and, . . - ^ 

populating a meta-model with data representing the 
core concepts and the relationships there between to 
thereby model the business domain. 

According to a sixth aspect of the present invention 
a computer program product comprises computer generated 
code mirroring a business domain, the computer program 
product including a business domain model which models the 
semantics of the business domain, and an infrastructure 
™odel which models the infrastructure of the business 
domain, wherein the business domain and infrastructure 
„K>dels are defined in terms of a meta-model, the meta-model 
comprising a number of concepts, each concept having a 
lumLr of properties, and one or more relationships between 
the properties of one or more of the concepts, wherein the 
relationships are defined as a concept within the meta- 

"^"^^^referablY. the infrastructure model is defined in 
terms of the same meta-model. More preferably, the meta- 
. nu^del is structured as a number of concepts, each concept 
having a nuPber of properties. and one or more 
relationships between the properties of one or more of the 
concepts, wherein the relationships are defined as a 
concept within the meta-model. 

Preferably, the meta-model is used to define a 
business domain model that represents a business or a part 

thereof . ^ . ^ «-vi-> 

The business domain model defines the semantics of the 

particular business application being modelled, whereas the 
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infrastructure model provides a physical context which 
allows the business domain to be implemented as required. 
Modelling the infrastructure separately therefore allows 
different business domains to be implemented using the same 
5 basic iniErastructure . This in turn allows alterations to 
the business domains to be implemented without having to 
redefine the infrastructure used by the business domain. 
Furthermore, this allows modifications of the 
infrastructure to be implemented without affecting the 

10 business domain models/ allowing infrastructure to keep 
pace with technological developments. 

The data which is used to populate the business domain 
and infrastructure models can include cuiy data relating to 
any aspect of the respective business domain. Thus, in the 

15 case of an airline company, the business data woxild 
typically include data relating to the aircraft used by the 
airline, as well as data regarding the number of users of 
the business model, the location of the airlines databases, 
and the like. Business data is not limited to simple data 

20 but can also include software components, for exan^le Java 
code, that implement business processes. Accordingly, it 
can be seen that the meta-model treats these software 
components as just another form of data. 

Different business data can be used by the business 

25 domain and infrastructure models. Thus, for example, diata 
regarding the aircraft would typically be used by the 
business domain model, whereas user data and database 
locations will typically be used by the infrastructure 
models, although this is not necessarily the case. 

30 In the present invention, each of the concepts 

includes a number of properties which are used to define 
each instance (or each specific example) of the concept. 
Accordingly, each instance of the concept will have 
respective property values. 

35 At least one of the properties of each concept 

represents a primary key, the primary key being xinicjue for 
each instance of the concept. Thus, one (or a combination 
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Of several) of the concept properties is arranged to be 
different for each Instance of the concept. This is done 
in order to ensure that each instance of a concept can be 
\iniquely identified. 

For example, if the concept relates to aircraft of an 
airline fleet, then each instance of the aircraft concept 
would correspond t6 a respective aircraft within the fleet, 
in this case, the properties of the- aircraft concept would 
relate to properties of the individual aircraft/ such as 
the aircraft type, or the like. As there will typically be 
several aircraft within the fleet of the same type, a 
primary key is defined, such as a aircraft identifier, 
which is different for each aircraft in the fleet, thereby 
allowing each aircraft to be uniquely identified. 

The relationships occur when a second concept is 
related to a first \ concept. In this case, one of the 
properties of the second concept represents a foreign key, 
the foreign key corresponding to the primary key of the 
first concept and representing the relationship between the 
two concepts. This allows information concerning the 
relationships to be defined within the properties of the 
concepts. 

in the above mentioned exaitple, a seat concept may be 
defined to allow the airline to run booking system for 
seats on the aircraft. In this case, each instance of the 
seat concept would define a seat within a given aircraft. 
It will be appreciated from this, that as each seat is 
uniquely defined, there will be a number of seats within 
the seat concept that relate to a particular aircraft. 
Accordingly, the primary key from the aircraft concept 
should be propagated to the seat concept as a foreign key, 
allowing the seats of a given aircraft to be easily 
identified. 

It should be highlighted that . in certain 
circumstances, the properties of some instances of a 
.concept can be related to the properties of other instances 
within the same concept. 
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In the present invention, the meta-model is adapted to 
be populated by datal In order to achieve this, each 
concept preferably defines a respective data table, each 
property defining a respective column within the table. 
5 Accordingly, the meta-model of the invention allows 

data to be entered in specifically desired tables so that 
. each instance of the concept is correctly defined. Thus in 
the above example, by carefully defining the properties of 
the aircraft concept, this can ensure that all the 
10 information required about the aircraft can be stored in 
the meta-model, allowing it. be used as required. 

From this, it will be appreciated that the properties 
of the concepts preferably remain invariant regardless of 
the circumstances in which the model is used. This allows 
15 the concepts to be reused in other business domain inodels. 

For example, the \ aircraft concept may include such 
properties as aircraft number and aircraft type which will 
be required whether the aircraft concept forms part of a 
seat booking system or an maintenance system. In this 
20 case, the aircraft . concept can therefore be used in both 

the seat booking and maintenance systems, although 

typically different relationships will be formed with the 
concept depending on the respective business domain being 
modelled. . 

25 In the seat booking example, the aircraft concept 

. would typically be related to a seat concep>t, whereas in 
the maintenance system example, the aircraft concept would 
typically be related to an operational status concept. 
Accordingly, if a model is to be adapted to apply to a 

30, different circumstance, for example if the aircraft concept 
is to be adapted to be relevant to a maintenance team as 
opposed to a booking system, then this can be achieved by 
sinqply altering the child concept of the aircraft concept. 
Alternatively, it is possible to define the properties 

35 of a concept such that the properties are unique to a given 
business domain. However, this makes the concept unique to 
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the respective domain and prevents reuse of the concepts in | 
different domains . - | 
For exatr^jle, if the aircraft concept is used in i 
booking airline seats, then the aircraft concept could J 
5 include properties such as the type of aircraft and the j 
number of seats provided thereon. In contrast, if the j::; 
aircraft concept is to be used by the maintenance team, 
then the concept would typicaliy include, properties 
regarding the operational status of the aircraft, including 

10 details of how many miles have been flown and when the last 
service was performed. 

The data tables are populated by entering instance |. 
data representing an instance of the respective concept, h 
the instance data being entered within a respective row of 

15 the data table. Accordingly, this allows the model to | 
hiandle each instance of a concept separately. In the 
example, details of each aircraft would therefore be 
specified in a respective row of the aircraft concept 
table. The data could however be stored in alternative 

20 ways. 

The meta-model preferably includes a "Concept" concept 
defining the concepts of the model to be defined, the 
properties of the "Concept" concept defining the properties 
of the concepts of the model to be defined. 

25 Accordingly, in the above example, the meta-model will 

include a concept that sets out details of each of the 
concepts used in the model being defined. Thus, in the 
exati5>le, instances of the "Concept" concept would include 
the aircraft concept and the seat concept. 

30 This allows certain features of the concepts to be 

specified, such as the name and a brief description of the 
concept purpose . This in turn allows users of the model to 
understand the model structure. 

The meta-model also includes a "ConceptProperty" 

35 concept which is related to the "Concept" concept. In this 
case, each instance of the "ConceptProperty" concept 
expresses a property of a respective concept defined in the 
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"Concept" concept • This can be achieved directly by 
defining each property separately within the 
"Concept Property" concept. 

Each instance of the "Concept Property" concept would 
5 specify a property of one of the concepts to be modelled, 
such as a property of the aircraft concept. Accordingly, 
if it is necessary to modify one of the properties of a 
concept , such as to change the value of the property from 
eui integer to a character string, then it is necessairy to 
10 make appropriate changes to the respective instance of the 
"Concept Property" concept. 

Alternatively a further concept, referred to as a 
. "CapProperty" concept can be used to define each property, 
with the "Concept Property" concept providing a mapping 
15 between instances of the "Concept" concept and the 
associated properties in the "CapProperty" concept, thereby 
allowing common definitions to be factored out. 

The meta-model includes a "ConceptKey" concept related 
to the "Concept" concept, each instance of the "ConceptKey" 
20 concept identifying the primary key of a respective concept 
defined in the "Concept" concept. This again allows the 
primary keys of the concepts to be determined. 

In addition to this, the meta-model includes a 
"ConceptRel" concept related to the "ConceptKey" concept, 
25 each instance of the "ConceptRel" concept identifying the 
relationships between the concepts defined in the "Concept" 
concept. 

With the concepts and relationships there between 
defined within the meta-model, this ensures that the model 

30 to be defined is self -consistent . It also has the effect 
that the meta-model can be defined in terms of its own 
structure, which in turn allows the models to be adapted 
and varied relatively easily. 

From the above, it will be realised that . the computer 

35 program product can be populated with data so as to define 
a .business model • In this case, the business model is 
usually associated with an infrastructure model which 
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models the business infrastructure; and, a business domain 
model which models the semantics of the business. 

Accordingly, the business domain model defines the 
semantics of the particular business application being 
modelled, whereas the infrastructure model provides a 
physical context which allows the business domain to be 
implemented as required. Modelling the business 

domains and the business infrastructure separately 
therefore allows different business domains to be 
in5>lemented using the same basic infrastructure. This 
allows alterations to the business domains to be 
implemented without having to redefine the infrastructure 
used by the business domain. This also allows 
modifications of the infrastructure to be implemented 
without affecting the business domain models, allowing 
infrastructure to \. keep pace with technological 
developments. 

For example, if new software is developed which allows 
improvements in the infrastructure to be achieved, this can 
usually be implemented without affecting the actual 
inplementation of the business domain. 

In this case, the infrastructure model is preferably 
formed from a set of individual models including, for 
example, a configuration model, an operations model , a 
process model and an install model, each of which are 
defined in accordance with the meta-model. However, any 
suitable infrastructure model could be used. 

In a preferred exati5>le, the configuration model 
defines how the computer program product should be adapted 
to take account of low level unstructured configuration 
data addressed at each of user, user-group, environment 
type and business processes. 

The operations model is adapted to model operational 
and statistical data on both a historical and live snap- 
shot basis . 

The process model models the current execution state 
of the . business domain model, each aspect - of execution 
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being represented by a respective concept within the 
process model. 

The install model defines the installation of the 
computer program product onto one or more operating systems 
and machines. Thus, the install model will define the 
supporting software and hardware systems, such as the 
operating and database systems. This will Include 
information regarding the location of data on the system, 
how resources, should be used by the computer program 
product, how information should be presented to a 
particular user on a screen, security access available for 
each user, ctnd the like. 

The infrastructure model set is preferably predefined 
in that the individual models in the set are defined in 
terms of the meta-model. This is because the business 
domain model is defined in terms of concepts and 
relationships, the meaning of which is only applied in the 
context of a specific domain model. Accordingly, as the 
majority of the infrastructure depends on the concepts and 
their relationships, ai3 opposed to the meanings of the 
concepts, this allows the infrastructure -to remain 
siabstantially invariant for different business domain 
models, which in turn allows the majority of the 
infrastructure to be predefined. Accordingly, reuse of the 
infrastructure can vastly reduce the amoimt of work 
required to model the business, ais well as providing 
confidence that the model will function correctly once 
defined. 

In this case, the infrastructure model is populated in 
accordance with user input business data. This provides 
any necessary context to the infrastructure model and is 
usually only required at a basic level, for example to 
ensure that information is presented to the user in a 
desired manner. In this context, the term "business data" 
includes Java code or other software applications; 

In the example of the airline, the booking system 
business domain may be implemented to • provide an 
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interactive representation of the aircraft which shows the 
actual location, of the seats, and allows these to be 
selected on the screen for booking purposes. In contrast 
to this, the maintenance... business domain would typically 
only require information concerning the repair status of 
seats on the aircraft. This can use a very similar data 
infrastructure without requiring a front end to produce the 
interactive representation. Accordingly, both business 
domains would use a similar infrastructure which only 
includes minor differences in the way the information is 

presented to the user- 

The computer program product can include a number of 
predetermined code portions which when operated in 
accordance with the infrastructure model allow the 
15 infrastructure to be implemented. These code portions 
define predetermined infrastructure implementations which 
can apply to many different business domains. 

It will also be realized that the code portions may be 
provided as part of a reference library allowing those 
portions of code which vary between domains to be selected 
in accordance with the context of the particular model. 

The business domain model is typically -implemented by 
populating the business domain model with business data 
representative of the business domain. 

For example,, in the case of an airline, the booking 
system business domain would require the input of data 
regarding the number of aircraft together with details of 
. the seating on each aircraft in order to allow the seat 
. booking system to function within the context of the 
30 airline. 

Once the business domain and infrastructure models 
. have been defined however, the computer program product can 
coirtoine the computer code portions with the input business 
data to generate applications software which. implements the 
model. Accordingly, this vastly reduces the amount of work 
required to design or redesign a business model and then 
inclement it. This in turn allows business models to be 
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updated more frequently to reflect changes in the business 
environment, helping the business remain con^etitive. 

The key features of the present invention are that it 
allows an application business model to be defined and 
5 modified quickly, easily and separately from the 
infrastructure codes; its speeds bespoke or package 
application development - by providing a developer with 
general purpose infrastructure code for the bulk of any 
business application; the application business model allows 

10 application code to be quickly customized and siibsequehtly 
modified as the business evolves; and it enables 
applications for the World Wide Web. Being model based, it 
is significantly more sophisticated, flexible, and useful 
than any other available product. It is able to provide 

15 businesses with dramatic time and cost savings compared 
with existing methods for developing or modifying business 
applications and, unlike other software products, it 
requires no radical re-engineering to respond to changing 
business needs. 

20 The present invention provides the ability to model 

the data and processes of a business in a unified and 
explicit framework. Within this modelling system, models 
can be customized and new business concepts and processes 
added with remarkable speed. The development and execution 

25 platform uses the definitions of the model* and provides 
most common application concepts and functions. Linking a 
specific business model with the pre-written infrastructure 
code enables the present invention to generate most of the 
code required to execute an application. Development 

30 productivity benefits from the modelling approach because 
the only concepts and functions that heed to be added are 
those that are unic[ue to the business. Standard software 
interfaces to common databases, data feeds, GUI components, 
etc, are provided. Single frameworks are also provided to 

35 customize platform integration, integrate new technologies, 
support custom GUIs etc. 
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The roeta-model of the: present invention makes the 
business semantics explicit and tangible. The model inposes 
a structure on the business semantics, thus preserving 
their "shape" and prevent the creation of an amorphous mass 
5 of code later in the development life cycle. The model 
also enables a clear separation of business semantics from 
the technology infrastructure. It also makes it possible 
to understand business applications, rationalise them, | 
discuss their behaviour in a meaningful way and manage | 
10 their development. 

Brief Description of the Drawings 

Ekamples of the present invention will now be 
described in detail with reference to the accompanying 

15 drawings, in which: I 
Fig. 1 is an overview of the hierarchy utilized by the | 

present invention; : 
Fig. 2A is a schematic diagram representing the 1 
structure of a concept in the meta-model of the present 

20 invention; : 
Fig. 2B is a schematic diagram representing the keys 
and relationships used in the meta-model of the present \ 

invention; ) 

Pig. 3 is. a schematic diagram representing the j. 

25 structure of a domain according to the present invention; | 

Pig. 4 is a schematic diagram of the Exe concept | 

utilized by: the present invention; i^ 

Fig. 5 is a schematic diagram of the verb and body f 

concept utilized by the present invention; | 
30 Fig. 6 is a schematic diagram of a non-relational 

concept utilized by the present invention; j 

Fig. 7 is a schematic diagram showing the model 

dependencies of . the infrastructure models used by. the i 

present invention; < 
35 Fig. 8 is a schematic diagram of. apparatus for 

iitplementing the present invention; . 
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Fig. 9 illustrates the structure of the computer 

program product of the present inventions- 
Fig. .10 is. an exaiqpie of the GUI of . the present 

invention; and, 

5 Figs, 11 to 20 show an example of the GUI of Fig. 9 

when applied to. the exanple of. an airline check- in 
. . procedure • 



10 Detailed Description 

The model execution application of the present 
invention may conveniently be supplied in the form of a CD- 
ROM that first requires installation on a cottputer or over 
a computer network before it can be run. The installation 

15 process and subsequent use of the model execution 
application to build executable models using the meta-model 
of the present invention will be described later. Firstly, 
we shall describe the structure of the model execution 
application, and the meta-model in particular. . 

20 As shown in Figure 1, the present invention uses a 

hierarchal structure in order to. model and ^ implement 
business processes. At the highest level, the model is 
defined in terms of a meta-model 1, the structuure of which 
will be described in more detail below. 

25 The meta-model 1 defines concepts and relationships 

which can in turn be used to define models. Because the 
meta-model allows any concepts and relationships to be 
defined, this allows the meta-model to be defined in terms 
of the concepts and relationships defined therein. 

30 Accordingly, the meta-model corresponds to a model of 
models which can be defined in terms of itself, as shown by 
the relationship 2. 

The next level of detail in the hierarchal structure 
shown in Figure 1 is formed from business domain models 

35 indicated . generally at 3, with one exanqple being shown 
specifically at 4. As indicated by the relationship 10, 
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each business domain model 4 is defined in terms of the 

meta-model 1.' 

Business domains are separate portions of a business 
which are capable of being identified independently, albeit 
sometimes with interactions with other business domains 
within the business. Each business domain can be defined 
in terms of certain core concepts and a number of 
relationships between these concepts, with each concept 
being a defined coherent entity that has certain properties 
and relationships with other concepts. 

Thus, for example, if the business is an airline 
company the business domains would typically include such 
portions of the business as seat booking system, aircraft 
maintenance systems, and the like- 

Typically, in order to define an entire business it is 
necessary to define\a number of business domains each of 
which is modelled by a separate model. 

Prom the above it will be realized that specific 
business domain models 4 are defined using the meta-model 
1 by mapping the concepts of the business domain model (and 
their associated interactions) as concepts (and, associated 
relationships) within the meta-model. This is usually 
performed by a skilled person, such -as a business analyst, 
or the like, who is able to identify the concepts and 
relationships within the business domain and then populate 

the meta-model. 

Thus, for example, the manner in which data is 
presented to a user will typically vary depending on the 
circumstances or business domain in which the present 
invention is used, . ^ 

in the example of an airline seat booking system, it 
is preferable for the user to be presented with the 
information regarding availability of seats , in the form of 
an aircraft outline representation, with each seat and its 
availability indicated in the corresponding location on the 
outline, in contrast, a maintenance system will typically 
only need information regarding a. seat number and its 
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repair histoiry^ and would not therefore require the 
aircraft outline representation. 

The meta-model defines a structure into which data and 
data representing models can be entered. The meta-model 
5 achieves this by allowing the concepts and relationships of 
the model to be defined in terms of a number of respective 
concept data tables, with the relationships being 
represented by appropriate links between the tables. 

At the same level as the business domain models, the 

10 structure also includes a number of infrastructure models 
5, including a process model 6, ah operations model 7, a 
configuration model 8, and an install model 9. These 
infrastructure models cooperate with each other to define 
the infrastructure of the business and in particular, how 

15 the infrastructure of the business should operate in order 
to implement the associated business domain model 4 . The 
fiinction of each of the infrastructure models 5 will be 
described in more detail below. 

Each of the infrastructure models 6, 7, 8, 9 are also 

20 defined in terms of the meta-model as shown by the 
relationships 11, 12, 13, 14; 

The use of the meta-model in this way meaois that the 
infrastructure models 5 are defined separately from the 
business domain models 3. This allows the same 

25 infrastructure to be used to implement any one of a nimiber 
of different business domains. This helps provide 
generality in the model such that a new infrastructure does 
not need to be defined every time a new business domain is 
inplemented. This in turn allows alterations to the 

30 business domains to be implemented relatively easily 
without having to redefine the infrastructure used by the 
business domain. This also allows modifications of the 
infrastr^icture to be implemented without affecting the 
business domain models, allowing the infrastructure to keep 

35 pace with technological developments. 

Thus, for exanqple, if new software is developed which 
allows improvements in the infrastructure to be achieved. 
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this can simply be implemented without affecting the 
business domain model , 

It will be realized from this that business domain 
software is software that is unique to a business. 
5 Accordingly, the business domain defines the semantics of 
the business application. 

In contrast to this, the infrastructure is the 
software that provides a physical context for the business 
domain software, allowing the business domain to be 
10 iii?>lemented as required. 

For example, the inf rastructure can be used to save 
and load data from a database, transmit data across a 
network, or display the data on a computer screen. The 
infrastructure can therefore be varied relatively easily 
15 depending upon the particular business domain to which it 
is applied. 

in order to aid this process, itt5>leraentations 15 are 
defined at the next level of the hierarchy which are used 
to populate the configuration model 8 and the install model 
20 9. Each individual implementation 16 is typically designed 
by a systems administrator or other specialist implementor 
to allow the application to be installed at a particular 
site ... 

Accordingly, once the business domain model has been 
25 designed, it is necessary to provide business data 19 which 
is specific to the particular business process being 
implemented. 

Thus, in the case of an airline seat booking system, 
it would be necessary to provide business data concerning 
30 the number and type of aircraft in the fleet, together with 
details of the passenger seating available on each 
aircraft. 

This form of business data 19 is entered after the 
model has been defined and is used to populate the business 
35 domain model 4, the process model 6, the operations model 
7 and the configuration model 8, as shown by the 
"relationships 20, 21, 22 and 23. 
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In addition to this form of business data. The 
business data 19 also generally includes request data 24. 
The request data is provided by a system user to request a 
business action. The business actions are the initiation 
5 of the execution of a business process, such as responding 
to a request for information, providing a service, or the 
like. 

The request data 24 may, as well as defining the type 
of req[uest, also include additional business data required 

10 to complete the request. 

Thus, in the case of an airline seat booking system, 
it would be necessary for a request to book a seat to 
include data indicating the seat which is to be booked, and 
this must be entered by the user during the seat booking 

15 procedure. 

The meta-model i utilised by the present invention 
will now be described in more detail with reference to 
Figure 2A, which shows the basic concepts within the meta- 
model, and Figure 2B which shows the keys and relationships 

20 between the concepts. 

As shown in Figure 2A the meta-model includes a 
"Concept" concept 30 including a number of. properties 31. 
The "Concept" concept is used to define the concepts used 
by the model currently being defined. 

25 Accordingly, each concept being used by the model 

would have to be entered as an instance within the 
"Concept" concept 30, with each of the properties 31 being 
defined. 

Thus, in this example, each concept (each instance of 
30 the "Concept" concept) should be assigned a conceptid, a 
name, a description, a collective name, a specialised 
class, a domainid and contentTypeld. However, these 
properties will depend on the nature of the concepts being 
defined and will therefore typically vary in different 
35 implementations. 
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The conceptid is an identifier uaed to tmiquely 
identify each concept defined within the "Concept" concept 
30, for a given business model . 

Thus, for exait5)le, in the case of aij airline check- in 
system, it will typically be necessary to have concepts 
relating to the seats available on the aircraft, the 
aircraft available in the airline fleet, the baggage 
allocation for an aircraft, and the check- in procedure. 
Accordingly, each of these concepts would, be assigned a 
separate conceptid. The conceptid is therefore typically 
a number which is unique for each concept . 

Every concept will have a respective property which is 
unique to each instance of a concept defined therein, and 
this property is known as a primary key (or "ConceptKey" as 
it is sometimes referred to) . Accordingly, in the case of 
the "Concept" concept, the primary key is the conceptid, as 
shown in Figure .2A by the underlining of the conceptid 
property. 

Related to the "Concept" concept 30 by relationship 32 
is a "ConceptProperty" concept 33, which is used to define 
the properties of instances of the "Concept" concept. This 
is achieved by having each instance of the 
"ConceptProperty" concept define a property of a respective 
instance of the "Concept" concept 30. Accordingly, a set 
of instances of the "ConceptProperty" concept will define 
the structure of a respective instance of the "Concept" 
concept 30. 

This therefore allows modifications to be made to the 
properties of a concept, such as to change the value of the 
property from an integer to a character string, by making 
appropriate .changes to the respective instance of the 
"ConceptProperty" concept. 

In this example, the "ConceptProperty" concept 33 
includes a -number of properties 34 including a 
ConceptPropertyld. a name, a description, a CapPropertyld 
and a Conceptid- In this case, as shown by the 
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underlining, the Concept Propertyld is the primary key of 
the "ConceptProperty" concept 33. 

The relationship 32 is knovm as a parent-child 
relationship in that each instance of a "ConceptProperty" 
5 concept* provides details of a respective one of the 
properties of an instcince of the "Concept" concept. 

In the airline check-in system example, an aircraft 
concept would typically be provided, with each instance of 
the aircraft concept providing details of a respective one 
10 of the aircraft in the airline fleet. 

A seat concept is also provided, with each instance of 
the seat concept providing details of a respective one of 
the seats in a given one of the aircraft. In this case, 
the seat concept provides details of the seats of the 
15 aircraft, and accordingly, the seat concept is related to 
the aircraft concept such that the seat concept is a child 
concept of the parent aircraft concept. 

In the Figures, the parent -child relationship is 
represented by an arrow, such as the arrow 32, with the 
20 arrow pointing from the child concept, in this qase the 
"Concept Property" concept 33, to the parent CQpcept, in 
this case the "Concept" concept 30. 

In addition to this, the nature of the relationship is 
specified by the text associated with the respective arrow. 
25 In this case, the relationship is a "1, 1 to many" 
relationship indicating that . for this relationship, the 
child concept will always have one parent concept, whereas 
the parent concept may have between one and many child 
concepts. Thus the text specifies "the number of possible 
30 parent concepts the child concept csm have, the number of 
possible child concepts the parent concept can have", for 
the specific relationship. 

In addition to this, there are other special cases. 
For example, one of these is where the nature of the 
35 relationship is "Type" meaning that the parent concept 
expresses the type of child concept. For example, an 
aircraft concept may be related by a "Type" relationship to 
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an aircraft type concept. Each instance of a "Type- 
concept therefore corresponds tP a domain level type. 

Another case is when the child is a specialisation of 
the parent concept, in vgrhich case the relationship is a 
"Superclass". For example a vehicle concept would be a 
"Superclass" of the aircraft concept. Both the 
-Superclass" and "Type" relationships are "1,0 to many- 
relationships. 

In order to allow a correlation between instances of 
parent and child concepts to be defined, the primary key of 
the parent concept is propagated to the child concept as a 
foreign key. This allows each instance of the child 
concept to include a cross reference to the relevant 
instance of the parent concept to which it refers. 

In the above example, an aircraftid would be used to 
uniquely identify each aircraft in the aircraft concept. 
In this case, aircraftid would be propagated to the seat 
concept as a foreign key, allowing the aircraft to which 
each seat in the seat concept belongs to be determined. 

Each seat defined within the seat concept would have 
a respective seatid, representative of the' individual seat, 
together with the indication of the aircraftid of the 
aircraft to which the seat belongs. 

In Fig. 2A. the foreign keys are indicated by italics. 
Thus, as shown, the conceptid f rom the "Concept" concept is 
propagated to the "ConceptProperty" concept as a foreign 
key, thereby allowing the relationship between the two 
concepts 30,33 to be defined. 

The "ConceptProperty" concept 33 is also related to a 
"CapPropertyV concept 35, having a number of properties 36, 
as shown by the relationship 37. 

The "CapProperty" concept 35 is an archetype of the 
. "ConceptProperty" concept and is therefore used to factor 
out common concept properties from the "ConceptProperty" 
concept 33 and to define the semantics of the properties. 

Thus, for example, every concept defined in the 
'"Concept" concept 30 will have a name property which is 
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used to allow the users to identify the relevant concept. 
Accordingly, irather' than define the name property 
separately for each concept, the name property would be 
defined a single time iri the "CapProperty" concept 35, The 
5 "Concept Property" concept 33 would then refer to the 
"CapProperty" concept 35 each time the name property is to 
be defined for a respective instance of the "Concept" 
concept, rather than defining the name property 
individually each time. 

10 ' in practice, the "CapProperty" concept 35 is used to 
define each property of each instance of the "Concept" 
concept, with the "Concept Property" concept providing a 
cross reference between instances of the "Concept" concept 
and instances of the "CapProperty" concept 35. 

15 In this exaraple, the properties 36 of the 

"CapProperty" concept\35 include a CapPropertyld, a name, 
a description, a def aultValue, a domainid, a CapbataTypeld 
and a CapPropertyContentld. As shown, the CapDataTypeld 
and the CapPropertyContentld are foreign keys of additional 

20 concepts (not shown in this exaiorqple) . 

The keys and the relationships between the, concepts 
are also defined in the theta -model, as shown in Figure 2B. 

In this case, the jprimary key of each concept is 
defined in a "ConceptKey" concept 40, which has a number of 

25 properties 41. These include a ConceptKeyld, which 
xmicgpiely identifies each primary key (and is therefore a 
primary key itself), a primaryind and a conceptld. The 
conceptid is a foreign key indicating that the "ConceptKey" 
concept is related to the "Concept" concept, although this 

30 relationship is not shown on the Figures 2A and 2B- 

Relationships between the concepts, such as the 
relationships 32, 37 are defined in the "ConceptRel" 
concept 42, Which is in turn related to the "ConceptKey" 
concept by the relationship 43 as shown. The properties of 

35 the "ConceptRel" concept 42 are shown at 44. 

The properties of the "ConceptKey" concept are defined 
in the "ConceptKeyProperty" concept 45, which includes the 
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properties 46, and which is related to the "ConceptKey" 
concept by a relationship 47 , The "ConceptKeyProperty- 
concept 45 is also related to the "ConceptProperty" concept 
33, as shovm by the relationship 48, as it defines the 
5 properties of the primary keys, which are properties of the 
concepts, and which are therefore also defined in the 
"ConceptProperty" concept 33. , . 

A "ConceptRelType" concept 49 is provided to define 
the types of relationships which are available between the 
10 concepts. This will generally include parent-to-child 
relationships and child-to-parent relationships, although 

others can also be defined within the properties 50 of the 
. "ConceptRelType" concept 49. It will be appreciated that 
the "ConceptRel" concept is related to the "ConceptRelType" 
15 concept 49 by the relationship 51. 

A "Ref ConceptKey" concept 53 having properties 54 is 
provided to define reference keys which are used across a 
number of properties, such as foreign keys. The 
"ConceptRelType" concept 49 is related to the 
20 "Ref ConceptKey" concept 53 by the relationship 55. 

The "RefConceptKey" concept 53 is in turn related to 
a "RefConceptKeyType" concept 56, haying properties 57, via 
the relationship 58. This defines the types of reference 
keys which are used within the model, such as a foreign 
25 . key.- 

Finally, a "RefConceptKeyProperty" concept 59 is 
provided to indicate whether a particular concept key is a 
member of a particular "RefConceptKey" instance. The 
"RefConceptKeyProperty" concept 59 includes properties 60 
30 and is related to the "ConceptProperty" concept 33 and the 
"RefConceptKey" concept 53 by the relationships 61 and 62 
respectively. 

When populated, the meta -model described . above with 
respect to Pigs. 2A and 2B defines models of business in 
35 accordance with the present invention. 

. In order to achieve this, as outlined above, the model 
includes a business domain model, to model the semantics of 
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the business for a particular business domain, as well as 
infrastructure models, which are used to allow the business 
model to be implemented • 

The basic business domain model structure which is 
used to generate specific business domain models 4 is shown 
in Figure 3. 

In this example, the structure includes a "Domain" 
concept 70 having a number of respective domain properties 
71, including a domainid (which forms the primary key of 
the "Domain" concept) , a nameUm, a description, a 
majorVersion, a minorVersion and a microVersion. ' 

Each instance of the "Domain" concept corresponds to 
a different business which is to be modeled by the present 
invention. 

In this example, the domain model also includes 
"URLAttrType", "Exe" ,\ "CapProperty" and "Concept" concepts 
72,73,74,75/ which are related to the "Domain" concept 70 
by the relationships 76,77,78,79, as shown. 

These concepts 72,73,74,75, are used to define various 
features of the domains which are instances of the "Domain" 
concept. 

In particular, the "URIAttrType" concept classifies a 
relationship between concepts of a given domain and non- 
relational data, with details of the relationship being 
specified in child concepts which will be described in more 
detail below with respect to Figure 6. . 

Thus, non-relational data such as documents like Word^ 
documents, which cam be accessed via a URL can be tied into 
specific concepts and insteuices of concepts, and Exes using 
the "URIAttrType" concept. 

The "Exe" concept 73 defines a business process which 
a domain will use. The "Exe" concept will be' described in 
more detail below but is used to define any form of 
executable procedxxre including "Verbs" & "Bodies" (which 
will also be described in detail below), software 
applications that are required to implement the specific 
domain model. 
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For exatiple, in the case of the airline maintenance 
system business domain, the "Exe" instance may include Word 
which would be required in order to view Word documents 
setting out the maintenance, procedures for the aircraft in j 
the fleet. 

In the case of the airline check-in system example, L 
typical instances pf the concept "Exe" would include r 
software for printing tickets, procedures iarid/or software I 
to validate the seating to be selected, and the like. 

The "CapProperty" concept 74 again, as in the meta- 
model, defines archetypes of "Domain" concept properties 71 | 
to reduce redundancy in the definition of the concept \^ 
properties for instances of the "Domain" concept. 

Finally, the "Concept" concept 75 is used to define 
15 the concepts used in each of the business domain models. I. 

It will be realised that the concepts 72,73,74,75 j 
represent the minimum concepts required to define a / 
business domain model, and in general additional concepts | 

would also be used. i 

20 Again, as in the meta-model, each of the concepts j 

72,73,74,75 includes respective properties 80,81,82,83, as j 
shown. 

^ In addition to this, the domainid of each respective ^ 
domain is propagated to the concepts 72,73.74,75 as a 

25 foreign key, as shown. / 
As mentioned above, when a business is to be modeled, r 
the business is first considered as a number of domains | 
into which the business can be divided. Each domain will 
then be defined as an instance of the -Domain" concept and 
30 be assigned a respective domainid. Additional properties 
of the domain will then be defined. 

in order to achieve this, data is entered into a 
"Domain" concept table within a database. The "Domain" 
concept table would include a number of columns, with each 
35 column corresponding to a respective property within the 
"Domain" concept. Each row in the table then corresponds 
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to a respective instance of . the "Domain" concept (i.e. a 
respective domain wlthin^^ the business) . 

An exanple of a partial "Domain" concept table, 
showing only the first three properties 71, for the case of 
an airline, is shown in Table 1 below. 



" Table 1 



domainld^ 


nameUrh 


description 


1 / 


domain: com. airlihecotnpany 
. domain . booking 


airline seat 
booking domain 


2 


domain : com. air linecompany 
. domain . maintenance 


aircraft 

maintenance domain 


3 


... 


... 



The analyst then considers each business domain in 
turn, and for each one determines . the core concepts of the 
respective business domain. Details of the core concepts 
are then entered into a respective "Concept" concept table. 

Again,, each column of the "Concept" concept table is 
used to define a particular property of the concept, with 
each instance of the concept being entered in a separate 
row. Thus, initially the analyst will define each concept 
as an instance within the "Concept" concept 75. 

Once this has been completed, relationships between 
properties of the different concepts are defined. Again, 
these relationships are expreaaed in a respective data 
table. By following this procedvire through, the concepts 
and relationships defined therein are entered within the 
tables. 

In this case, the relationships and keys are also 
defined within the appropriate "ConceptRel" , "ConceptKey" 
and "Ref ConceptKey" concepts 42, 40, 53 within the meta- 
model. 

The inclement at ion of the "Exe" concept 73 will now be 
explained in more detail with respect to Figtire 4. As 
shown, the "Exe" concept 73 is related to an 
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"ExeContentType" concept 9 b which has a nuniber of 
properties 91, via the relationship 92. 

The "ExeContentType" concept 90 specifies the 
different types of "Exe" concept that are defined in the 
5 model. thus, for exaitple, as mentioned above, this can 
include applications, such as Word, Excel, or the like, as 
well as "Verbs" arid "Bodies" (which will be explained in 
more detail below) and other executables. 

The type of each instance of the -Exe" concept 73 is 
10 therefore defined in the "ExeContentType- concept 90. 

Also included in Figure 4 is a "Body- concept 93, 
which has a number of properties 94. and a "Verb" concept 
95, having a nuniber of properties 96, which are related to 
the "Exe" concept by the relationships 97 and 98, 

15 respectively. 

Verbs are a specialist form of Exe which are used to 
generate an output in a predetermined format. The Verbs 
are therefore generally formed from structured Java code 
which is designed specifically to perform required 
20 operations. In turn, the Bodies are algorithms which are 
used by the Verbs in order to generate thfe desired output. 
To support the type-safe implementation of Body code, a 
code generation step exists in which the business domain 
model is directly reflected in Java classes. This means 
25 the algorithms can be implemented directly in the concepts 
of the domain model, thus making the algorithms more 
readable. Accordingly, it can be seen that Verbs are 
another instance of "business data" (comprising meta-model 
entries and sotirce code) . 

instances of the "Body" concept 93 define different 
start points which may exist for . a Verb which is an 
instance of the -Verb" concept. Thus, for example, if a 
number of different start points are available for a 
specific operation, then eaqh body defined within the 
35 "Body" concept represents an algorithm which is able to 
perform the iinplementation based on. a specific start point. 
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An example o£ such a .system is the use of a verb to 
calculate the- pay provided, to workers by a company. 
Typically, the pay will be effected by whether the person 
being paid is an employee^., or an outside contractor, as 
5 . well as being effected by whether the work was performed 
inside or outside the^EU (European Union). 

Accordingly, in order to be able to handle this, four 
separate bodies would be provided. These bodies will be 
algorithms designed specifically for calculating the pay 

10 for each of the four different circumstances. Thus,; a 
respective body will be provided for calculating the pay of 
an employee inside the EU, the pay of an employee outside 
the EU, the pay of a contractor inside the EU, and the pay 
of a contractor outside the EU. 

15 In each case, the algorithm is designed to calculate 

the pay on the basis\ of data provided to the bodies, the 
data indicating the nature of the worker (i.e. whether the 
worker is an employee or a contractor) , and where the 
worker was working. 

20 In practice, this is achieved by initially 

transferring the data to the verb. The verb examines the 
data and determines which body will be capable of receiving 
data and calculating the correct pay. The data is then 
trcunsf erred to the body which calculates the pay and 

25 returns an indication of the calculated pay to the verb for 
.• subsequent output . 

This represents a significant improvement oyer 
previous object orientated techniques because the verb 
makes the choice of which body should be used to calculate 

30 the desired output. Thus, using object orientated 
programming techniques it would be necessary for the 
programmer to determine the choice of how the pay should be 
calculated using for example "IP" statements. In this 
case, because the choice . would typically, have to be 

35 specified several times within the programming code, any 
change would have to be reflected throughout the program 
code. Thus, the use of Verbs in the present invention 
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ensures that if a change is required, this can be 
implemented by , simply changing the algorithm associated 
with the Body and/or changing the relationships between the 
Body and the corresponding Verb. 
5 Accordingly, from this it will be realised that each 

Verb is associated with a collection of one pr more Bodies, 
with each Body being used by the Verb to. generate the 
desired output from a respective start point. 

The relationship between the "Verb" concept and the 
10 "Body" concept is shown in more detail in Figure 5. 

AS shown, the "Body" concept 93 is related to the 
"Verb" concept 95 by a relationship 99. 

Also related to the "Verb" concept 95 is a 
"VerbOutput" concept 100 having a number of properties 101. 
15 in this case, the "VerbOutput" concept 100 defines the 
nature of the output produced by the appropriate verb 
within the "Verb" concept 95. 

AS the bodies defined within the "Body" concept 93 
. must be capable of receiving inputs in different formats a 
20 -Verblnput" concept 103 is provided with a number of 
properties 104. The "Verblnput" concept 103 is used to 
determine the nature of input data and then select an 
appropriate instance of the "Body" concept 93 depending on 
the nature of the data, as indicated by the relationship 
25 105. 

A "VerbThrowable" concept 106 is also provided. 
Again, this includes a number of properties 107 and is used 
to define when the processing performed by a Verb has an 
exception. Again, the "VerbThrowable" concept 106 is 

30 related to the "Body" concept 93 by relationship 108. 

Returning to Figure 4, in addition to the "Body" and 
"Verb" concepts 93,95 an "ExeConstraint" concept 109 is 
provided having properties 110. The "ExeConstraint" 
concept 109 defines constraints on the Exes defined as 

35 instances of the "Exe" concept 73, as shown by the 
relationship 111. 
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The "ExeConstraint" concept 109 is also related to an 
"EnvType" concept- 112 by a relationship 113. The "EnvType" 
concept 112 is used to define a different operating 
environment in which the system may operate/ 

For example, if the Bxe is a software application such 
as Word, or the like, it is possible to operate this Exe 
under the Windows'** operating environment on a personal 
computer, or the like. However, it is not possible to 
operate these under; for example, Unix type environments. 

This places a constraint on the use of the respective 
Exe which is defined within the "ExeConstraint" concept 
109, which specifies for each "Exe" concept instance the 
environment within which the respective Exe can be used. 
To allow this to be achieved, the uscdDle environments are 
specified in the "EnyType*' concept 112. 

A mime is used to classify files euid has associated 
with it a suffix which is typically placed on file names to 
define an association between the file and a particular 
program. Thus, for example, the suffix " .DOC" is typically 
associated with the Word™ application. In order to define 
the association between certain suffixes and particular 
Exes, the "MimeEditor" concept 117 (which has properties 
118) is populated. The "MimeEditor" concept 117 is related 
to both the "Mime" concept 115 and the "Exe" concept 73,: as 
shown by the relationships 119 and 120 respectively. 

For exanple, in the case of an airline maintenance 
system business domain, it will be necessary to provide 
information regarding the maintenance log procedures for 
the aircraft in the fleet. This infortnation is usually 
maintained by the engineering department in the from of a 
Word document, PDF file, or the like which is XJRL 
addressable. This URL address is then associated with an 
appropriate concept in the maintenance system business 
domain allowing the documents to be easily located at a 
later date . 
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The concepts and relationships required to iirplement 
this are shovrai in Figure 6. 

As shovm, a "URLConceptAttr" concept 125 having 
properties 126 is provided. The "URLConceptAttr" concept 
is used to define associations between instances of the 
"Concept" concept 75 and respective URL locations shovm 
generally at 127, with each instance of the 
"URLConceptAttr" concept 125 representing a respective 
.association. 

As a result, •« URLConceptAttr" concept 125 is related 
to the URL of the concept by a relationship 128 and to the 
"Concept" concept 75 by the relationship 129. 

Similarly, a "URLAttr" concept 130 is provided, having 
properties 131, to allow each instance of each concept 
{instance of the "Concept" concept) to be assoicated with 
a; respective URL shown at 132. 

Accordingly, the "URLAttr" concept 130 is again 
related to the URL of each concept instance 132 by the 
relationship 133 and is also related to the "Concept" 
concept 75 by the relationship 134. 

A "URLExeAttr" concept 135 is provided having 
properties 136. The "URLExeAttr" concept 135 is again used 
to allow each instance of the "Exe" concept to be associatd 
with a respective URL location, as shown at 137. Again, 
the "URLExeAttr" concept 135 is related to the location of 
each URL by the relationship 138 and to the "Exe" concept 
73 by the relationship 139. 

A "URLAttrType" concept 140 is provided to classify 
the different URLs which can be accessed, namely the URL of 
an Exe 137, the URL of a concept instance 132, and the URL 
of a concept 127. . This is indicated by the relationships 
142,143,144 as shown. 

The "URLAttrType" concept 140 is also related to a 
"URLStringType" concept. 145, which indicates the type of 
URL string which must be used to access each type of URL. 
. In this case, the relationship is shown at 147. 
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Furthermore,, a ^Suffix" concept. 148 is provided which 
is related to the "URIAttrType" concept 140 as shown by the 
relationship 150 to allow' different mime suffixes to be 
applied when the URLs are being accessed. 

Accordingly, non-relational data, is handled by tying 
the data in to respective concepts within the meta-model. 
Once the relationship has been defined, for example, this 
allows a user of the system to easily to access a 
particular maintenance log due to this defined association. 

The infrastructure models will now be described in 
more detail with reference to Figure 7, which shows the 
infrastructure models cind the relationships therebetween. 

In addition to the relationships defined in Figure 1, 
the process model 6, the. operations model 7 the 
configurations model 8 all depend on the install model. 9, 
as shown by the relationships 160,161,162. In addition to 
this, the operations model 7 also depends on. the process 
model 6 as shown by the relationship 163. 

The process model 6 models the current execution state 
of the business domain model, each aspect of execution 
being represented by a respective concept within the 
process model. 

This is achieved by defining riinning processes as 
concepts within the process model • Data is then captured 
from the remaining infrastructure and business domain 
models, and used to populate the process model so that the 
process model effectively maintains a snapshot of the 
execution of the business model in its current state, as 
well as maintaining a historical record of previous 
operations. 

The process model also takes into accoxont the 
environment in which the business model is being 
implemented, allowing the process model to determine the 
resources that are available. 

In addition to this, the process model can be adapted 
to store information regarding previous actions which have 
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been performed. This allows a history of the actions which 
have been performed by users to be viewed • 

Thus , a user of the system can at any time access the 
process model and determine not only what processes are 
currently being performed and where, but also what has been 
performe^d in the past, and what the current available 
resources are . 

The operations model 7 is, adapted to model operational 
and statistical data on both a historical and live snap- 
shot basis. This is achieved by populating the operations 
model with status and audit data generated by the business 
process model,, allowing the information to be viewed as 
required. 

The install model 9 defines the installation of the 
computer program product carrying the model execution 
application onto one or more operating systems and 
machines. Thus, the install model will define the 
supporting software and hardware systems, such as the 
operating and database systems. This will include 
information regarding the location of data on the system, 
hpw resources should be used by the computer program 
product, how information should be presented to a 
particular user on a screen. 

In order to do this, the install model is populated so 
as to determine certain information regarding the operating 
systems and platforms, for example datcO^ases, data feeds, 
on which it is to operate. 

This will typically include details of the hardware on 
which the software is to run, such as the presence of a 
network, the computers which will be used, the location of 
any external d^ta soxxrces, and the like. 

Once this has been completed, the install model will 
conprise a repository of where data, including the business 
model concepts, and the business data are stored. 

The install model is also used to define user 
settings, such as user names, passwords, security 
privileges and the like . . ^ 
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The configuration model 8 defines how the computer 
program product should be adapted to take account of low 
level xmstructured configuration data addressed at each of 
user, user-group, envirdnmerit type and buisiness processes. 
5 An exianqple is for the configuration niodel to be used 

to control how often a fax machihe will redial a number 
when a connection cannot be established at the first 
attempt, whereais in this case of a dlock, the configuration 
model can be used f or exan5)le to control the frequency with 

10 which the clock is updated. 

In general, the hierarchical structure of the 
configuration model is such that user settings are given a 
higher priority than group settings, environment (machine) 
settings and Exes settings, in turn. Thus, for example, it 

15 may be that a certain group within the company, such as the 
Accounts Department, have their computers set up to present 
the accoxints information in a certain way. However, an 
individual user setting could then be used tb ensure that 
one particular member of the Accounts Department has the 

20 account information presented on their computer in a 
different way. In practice however there is generally very 
little overla:p between the different classes. 

The process of designing and implementing a business 
model will now be described. 

25 Firstly, as outlined above, it is necessary for an 

analyst to perform an analysis of the business in order to 
divide the business into a number of independent business 
domains, each of which can be modeled separately. 

Once this has been completed, the analyst can model a 

30 business domain by determining the core concepts of the 
business domain and their relationships. This is then 
defined in terms of the meta-model by generating and then 
populating appropriate data tcd^les. 

The procedures of analysing the busineiss and 

35 determining the concepts in the business domain will 
typically be coalesced so that they CeUi be performed in an 
iterative manner to allow the! analyst to use information as 
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it is determined to improve the business -model , as will be 
appreciated by: a person skilled in the art. 

In practice, the present invention would typically be 
implemented as an enterprise application, within in a 
corporation and an example of such a configuration is shown 
in Figure 8 . 

In this case, the enterprise application consists of 
corporate network 300, to which is coupled a file server 
301, a data server 302, and a number of end stations 303. 

In use, the software for operating the present 
invention is provided on a CD-ROM that must initia:lly be 
installed on the system. The structure of the computer 
pr'ogram product 400 is shown graphically in Figure 9- As 
indicated, the product is made up of a number of high level 
code packages, each package being represented by one layer 
in the structure. Each pagkage is potentially dependent on 
those beneath it. The packages can be divided up into 
distinct groups: those that are provided with the CD-ROM 
401; those that are provided by the system software vendor 
402; those that are provided by a modeller or programmer 
developed using a code generator associated, with the 
product 403; and those that are provided by the modeller or 
programmer 404. The structure 400 represents a single 
process, within which there may be a number domain 
dependent modules 405 sitting over the xinderlying packages. 
One of these modules is the meta-model, which is already 
provided on the CD-ROM. 

At this stage, the infrastructure, model (the 
installation model and configuration model components) 
presents a user interface that allows a systems 
administrator to install the various software components 
provided on the CD-ROM. 

The systems administrator is presented with an 
installation wizard that takes him through, this process, 
allowing him. to populate the infrastructure model with 
implementation data defining the installation of the 
product onto one or more operating systems and machines. 



The installation model allows him to define (by populating 
the model) the supporting software and hardware systems, 
such as the operating and database systems.. This includes 
the location of data on the system, how resources should be 
used by the product, how information should be presented to 
a particular user on a display screen, security access for 
each user, and the like. Likewise, the configuration model 
: can be populated with: data defining how the product should 
take account of low level vmstructured configuration data 
addressed at each of user, user group, cuid environment and 
business processes. 

As shown, in this example the meta-model and 
infrastructure models are stored in the data server 302, 
with the source and object code of the meta-model and 
infrastructure model being stored in the file server 301. 

Having achieved the initial installation, an analyst 
or systems developer Ccui then use one of the end stations 
303 to access the modeling software of the present 
invention and generate business domain models, as described 
in more detail above. 

As this is performed, the business domain mpdels are 
written into the data server 302 as a number of related 
data tables. 

Once this has been /completed, a programmer will be 
used to generate applications specific source code, which 
is stored in the file server . 301 ^ The applications 
specific source code is amy source code which is required 
for the specific business domain model being iit5>leraented. 
This is typically used, for exanple, to ensure that data is 
presented to the user in the form of a readily 
understandable representation. 

The next stage is for the systems administrator or 
systems developer to generate fxirther implementation data 
which is used to populate the infrastructure model (the 
installation model and configuration model components) that 
allows the process of the business domain- model ^o be 
executed. These may include algorithms and the like which 
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are not defined within the infrastructure model but which 
are required to implement the business. 

Next it is necessary to populate the business model 
with business data representative of the business. This 
business data may be obtained from a number of sources 
depending on the nature of the data and the circumstances 
in which it is provided. 

A large amount of the data typically has to be entered 
by hand using one of the end stations 303. However, data 
regarding the facilities of the business may be available 
from an external source, in which case, this can be 
obtained from a data feed (not shown) . It is also possible 
to obtain data from the Internet, or the like. 

Once the initial business data has been provided, it 
is then possible to operate the business model. During 
operation, any data t:hat is required can either be entered 
by the respective user of the system, such as request data, 
or can alternatively be obtained from the data server 302 
in the case of business data. 

In order to make this process easier, the present 
invention is typically implemented as a software program 
which provides the user with a GUI (graphical user 
interface) which presents the information to the user in a 
conceptual memner. 

In its basic form, the present invention can therefore 
be implemented on the processing system, such as a personal 
computer, laptop, palmtop, or the like. However, it is more 
likely to be installed over a network. 

As shown, the GUI in Figure 10 coitprises a modeling 
screen 210 on which the model under construction is shown. 
Positioned below the modeling screen 210 is a 
concept/properties screen 211 which shows either the 
details of a concept, or the details of each property of 
the concept depending on whether the concept tab 212 or the 
properties tab. 213 has been selected. Positioned above the 
modeling screen 210 is a tool bar 214 which includes an add 
concept icon 215, a save all icon 216, a move concept icon 
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217, a create relationships icon 218, a- details icon 219, 
amd a delete icon 220, as shown. 

in use, a model is generated by activating the add 
concept icon 215 to allow a concept to be defined. As will 
5 be e3q>lained in more detail below; once details of the 
concept have been entered, this causes a respective concept 
box, shown by the dotted line 221, to be presented to the 
user on the irodeling screen. Once a number of concepts 
have been defined. It is then possible to rearrange the 

10 positioning of the concepts by selecting the move concept 
icon and then clicking and dragging on the respective 
concept box 221. Relationships can then be created between 
the concept box by simply clicking on the create 
relationships icon 218 and then clicking and dragging from 

15 one concept box 221 to another. Details of the concepts 
can then be entered By clicking on the details icon 219. 
The defined model can then be saved by selecting the save 
all icon 216. At this point, a code generator (not shown) 
is invoked so as to prepare the model for execution and/or 

20 fiirther development. Portions of the model can be deleted 
as and when necessary using the deletion icon 2.20. 

In use, as a concept is defined, it is given a 
respective name which is entered using the input device, 
and which is then entered into the name property of the 

25 "Concept" concept tcJDle by the processor 202; 

Once this has been completed, other properties of the 
concept are also entered in a similar manner. 

As the relationships are entered using the GUI, the 
processor 202 similarly operates to enter respective data 

30 within the relationships concept. Simultaneously, a 
primary key and a foreign key are defined. Accordingly, in 
this manner a model of the business showing the core 
concepts and the relationships there between is defined in 
accordance with the raeta-model. 

35 Once this has been completed, and all the properties 

of each of the concepts have been defined, it is then 
possible to enter the business data in the respective 
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tables which have been generated by the processor 202 which 
represent instances of the respective concepts • 

This process will now be described in more detail with 
respect to the example of an airline check-in system. In 
5 this case, the designing of this business domain model 
would be as shown in Figures 11 to 19 as set out below. 

Thus, as mentioned above, the first stage is to define 
an aircraft concept. This is achieved by clicking on the 
add concept icon 215. which causes an input box 222 to be 

10 displayed as shown- Details of the concept name are then 
entered at 223 and the OK button 224 selected to proceed to 
the next stage. A cancel button 225 is also provided to 
cancel the operation. 

Once this has been completed, an aircraft concept will 

15 be displayed on the modeling screen 210. An exanple of the 
modeling screen 210 including both an aircraft concept 230 
and a seat concept 231 is then shown in Figure 12. 

Once the aircraft and seat concepts 230, 231 have been 
defined, it is then possible to define a relationship 232 

20 therebetween. This is achieved by clicking on the create 
relationships icon 218 to enter a "relationships mode". 
Once this has been achieved, the relationship is then 
defined by first selecting the respective one of the 
concepts and then clicking and dragging the cursor to the 

25 other concept to create the relationship. The direction in 
which this is done will define the relationship. 

Accordingly, in this example, the seat concept 231 is 
the child concept of the aircraft concept 230. 
Accordingly, to define a relationship 232, which is shown 

30 in Figure 13, the user would select the relationships icon 
218 to enter the relationships mode and then click on the 
seat concept 231. The ciirsor would then be dragged to the 
aircraft concept 230 causing the relationship 232 to be 
defined. 

35 • Defining the. relationship 232 will cause the. processor 

202 to define a relationship within the corresponding data 
. tables of the meta-model. This is achieved by defining a 
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Concept Key entry on the aircraft concept 230 and defining 
a RefConceptKey entry on the seat concept 231, as described 
in more detail above. 

In order to do this, it is of course necessary to 
5 enter the properties of the concepts. In order to achieve 
this, the details icon 219 is selected and the concept tab 
.212 highlighted. As shown in Figure 14, this will cause: 
details of the currently selected concept (in this case the 
seat concept) to be displayed in the concept /properties 

10 screen 211. This typically includes a name column 235,:^ 
which shows the name of the concept, a description column 
236 which provides a brief general description of the 
concept, and a collective name column 237 which provides a 
collective name for the instances of the respective 

15 concept. 

First, once the ^eat concept 231 has been defined, the 
user will then select the details icon 219 and enter the 
respective description and collective name in the 
respective description and collective named columns 236, 
20 237. 

This process can be repeated for each conc.ept and in 
order to find the details of the relevant concepts, the 
respective concept 230, 231 must be highlighted on the 
modeling screen 210 so that the details are displayed in 

25 the concept /properties screen 211. 

Once the concepts themselves have been defined, it is 
then possible to define the properties of the concept. In 
order to do this, the properties tab 213 and the details 
icon 219 must be selected to display the properties of the 

30 respective concepts in the concept /properties screen 211.. 
Once this has been completed, properties can be added or 
removed using the add property or delete property icons. 
238, 239, as required. 

Selecting the add properties icon 238 causes a 

35 properties input box 240 to be displayed on the modeling 
screen 210, as shown in Figure 15- The properties input 
box 240 includes an entry field 241 into which the name of 
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the respective property can be entered. Once this has been 
completed, the okay button 242 is depressed. Again, a 
cancel button 243 is also provided. 

Once the okay button 242 has been depressed, the 
respective property name will be entered in a name colunm 
244/ as shown with the previously defined aircraft ID and 
seat IP properties. 

Once the property has been entered, the processor 202 
operates to attett4>t to assign a description to the 
property- This, in the case of the aircraft IP property 
this is also included as a primary key within the aircraft 
concept- Accordingly, the processor 202 determines that 
the aircraft ID is in fact a foreign key to the aircraft 
and then enters this is the relevant description column 
245- Similarly, the processor 202 works out that the 
aircraft ID is now. part of the seat concept which is 
entered in the part of column 246. 

In either of these cases, if the description or part 
of the properties of the concept cannot be determined by 
the processor 202 then these details are entered by the 
user. . • , ^ 

Finally, it is necessary for the user to specify the 
type of value the property will take, such as an integer, 
a character string, a floating point number or the like and 
this is entered into the wrapped instance of column 247 as 
shown. 

Thus, in the example shown in Figure 15, once the 
fabric property name has been defined, a new entry will be 
created in the name column 244 as shown at 248 in Figiare 
16. In this case, details have also been entered in the 
relevant description, part of and wrapped instance of 
columns 245, 246, 247 as shown. 

In this manner, it is then possible to add in all the 
concepts required to implement the respective business 
domains. 

. Accordingly, in the present example of ' the airline 
check- in. system, in addition to the aircraft concept 230 
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and the seat concept 231, it is also necessary to define a 
flight concept. 250 which, provides details of respective 
flights, a ticket concept 251 which provides details of the 
tickets provided, a customer concept 252 which provides 
5 details of the respective customer, an address concept 253 
which provides the customers address, and an address type 
254 which defines the nature of the customers address. 

A seat type. and aircraft type concepts 255, 256 are 
also provided to specify the type of seat, such as first 

10 class, economy, window, aisle seat and the type of 
aircraft, such as a Boeing 747 or the like. 

Finally, a track concept 257 and a location concept 
258 are used to identify a link between two locations and 
an airport, respectively. 

15 Relationships are then defined between the concepts as 

shown. 

Once all the concepts have been defined as shown in 
Figure 17 it is then possible to populate the model with 
data (which may take the form of Java code) . 

20 In general, this process would include two stages. 

Firstly, it would be necessary to populate the nvodel with 
data representative of the business resources. Thus, for 
exanqple, the data table corresponding to the aircraft 
concept 230 would be propagated with data representing 

25 details of the relevant aircraft owned by the airline 
company. Similarly, this will be performed for each of the 
concepts within the current business domain model. 

In order to achieve this, a data editor is used and an 
example of this is shown in Figure 18. As shown, the data 

30 editor includes the modeling screen 210 to show the 
business domain model. Below the modeling screen, however, 
is positioned a details screen 260 which shows details of 
data entered into different concepts. In this case, 
entries are added by clicking on the add entry button 261 

35 and removed by clicking on the delete entry button 262. 

. Once the background data showing the resources of the 
company has been entered, it is then, possible to enter 
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specific data relating to actual bookings. Accordingly, as 
shown in the present, exatrple of the airline booking system, 
a price column 265, a booking column 266, a booked by 
column 267 and booked on column 268 are provided. These 
5 indicate the price of the seat, the seat which is booked, 
the name of the person making the booking , and the item 
which this is booked, respectively. 

The process of adding .in a particular entry is shown 
in more detail in Figure 19. As shown, when the add entry 

10 button 261 is selected, an input box 270 for creating a new 
concept instant entry will be displayed. In this example, 
the concept instance to be created is an instance of the 
ticket concept 251 (i.e. the procedure creates a new f 
ticket), and accordingly, the ticket concept would need to j 

15 be selected before the add entry button 261 is pressed. 

Once this has happened, the create new ticket input 
box 270 will be displayed. Within this box there will be 
included separate fields 271, 272, 273, 274 which are 

■ i 

provided to allow a person to input a price, a qeat number, 

20^ . a detail of who booked the ticket and a detail of the | 
flight as shown. These fields are generated in accordance | 
with the properties of the ticket concept which will have 
been defined as described in more detail above. 

Accordingly, this system provides a model which can be 

25 executed by the business to implement the respective ! 
business domain. 

However, the way in which the information is presented 
to the user as a default is not necessarily very intuitive. | 
Accordingly, it is possible to define an interface which 

30 will translate the manner in which information is provided 
to the user. An example of this is shown in Figure 20. In 
this case, the data editor for adding a ticket has been 
adapted to replace the model screen 210 with the screen 280 
which includes an aircraft representation shown at 281. 

35 The aircraft representation sets out the location of 

seats in the aircraft as shown for example at 282 together 
with details of the different classes of seat available at 
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283, 284 and 285, and an indication of the actual seats 
available in each class shown at 286, 287, 288, This csui 
be achieved relatively easily by simply providing a 
translation of the data provided in the concepts of the 
5 respective airline booking system business domain model. 
As a result, the user is presented with a far more 
intuitive way of entering the data. 

Thus for example, the aircraft representation 281 will 
be generated by reference to the seat concept . 

10 Accordingly, each seat representation 282 will be tied to 
a respective instance in the seat concept table. Selecting 
the relevant seat representation 282 will therefore cause 
the data in the relevant seat concept table to be selected. 
Thus, if the operator of the system selects a seat 

15 representation 282 and then clicks on the add entry button 
261, this will automatically generate a create new ticket 
concept instance box 270 which includes details of the seat 
282. The seat would typically be associated with a 
respective price and accordingly, the information Ccui 

20 automatically be propagated into the create new ticket box 
270 in the respective fields 271, 272, 273, 274 ,such that 
only unknown information, such as the name of the person 
booking the ticket needs to be entered. 
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CLAIMS 

1. A computer program product comprising computer 
executable instructions defining a model execution 

5 application, the model execution application implementing 
a meta-model which is adapted to be populated with user 
inputs to generate one or more models, the meta-model being 
structured as a number of concepts, each concept having a 
number of properties, and one or more relationships between 
10 the properties of one or more of the concepts, wherein the 
relationships are defined as a concept within the meta- 
model. 

2. A computer program product according to claim 1, in 
15 which the meta-model includes an active concept which can 

be populated with software conponents. 

3 . A computer program product according to claim 1 or 2 , 
in which the model execution application conprises a 

20 computer program code portion that provides access to the 
meta-model and which is adapted to accept user ...inputs to 
allow a model to be generated. 

4. A computer program product according to any preceding 
25 claim, in which the model execution application conprises 

a program code portion that provides access to models 
generated using the meta-model so that the models can be 
executed by one or more users. 

30 5. A computer program product according to any preceding 
claim, in which the model execution application conprises 
an infrastructure model defined in terms of the meta-model 
that facilitates the execution of the meta-itradel and any 
models generated using the meta-model. 

35 

6. A computer program product according to claim 5, in 
which the infrastructure model is adapted to accept user 
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defined implementation data inputs to populate the 
infrastructure model. . 

7. A computer program product according to claim 5 or 6, 
in which the infrastructure model is adapted to present a 
user interface that allows the meta-model to be installed 
and executed by a user. 

8. A computer program product according to any of claims 
5 to 7, in which the infrastructure model con?>rises an 
install model defining the installation of the computer 
program product . 

9 . A computer program product according to any preceding 
claim, in which at least one of the properties of each 
concept represents a primary key, the primary key being 
unique for each instance of the concept. 

10. A computer program product according to any preceding 
claim, in which when a second concept is related to a first 
concept, one of the properties of the second concept 
represents a foreign key, the foreign key corresponding to 
the primary key of the first concept and representing the 
relationship between the two concepts . 

11.. A computer , program product according to any preceding 
claim, in which the raeta-model is adapted to be populated 
by data, each concept defining a respective data table, and 
each property defining a respective column within the 
table . 

12. A computer program product according to claim 11, in 
which the data tables are populated by entering instance 
data representing an instance of the respective concept, 
the instance/data being entered within a respective row of 
. -the data table. 



50 

13. A computer program product according to claim 12, 
wherein the instance- data specifies the properties of the 
instance of the concept. 

14. A computer program product according to any preceding 
claim; in which the meta-model includes a "^Concept" concept 
defining the concepts of the model to be defined, the 
properties of the "Concept" concept defining the properties 
of the ^concepts of the model to be defined. 

15. A computer program product according to claim 14, in 
which the meta-model includes a "Concept Property" concept 
which is related to the "Concept" concept, each instance of 
the "ConceptProperty" concept defining the properties of a 
respective concept defined in the "Concept" concept. 

16 . A conputer program product according to claim 14 or 
15, in which the meta-model includes a "ConceptKey" concept 
related to the "Concept" concept, each instance of the 
"ConceptKey" concept identifying the primary key of a 
respective concept defined in the "Concept" concept. 

17. A computer program product according to any of claims 
14 to 16, in which the meta-model includes a "ConceptRel" 
concept related to the "ConceptKey" concept,, each instance 
of the "ConceptRel" concept identifying the relationships 
between the concepts defined in the "Concept" concept. 

18. A computer inplemented method of generating a software 
application conprising the steps of: 

populating a meta-model with data to define a model; 
and, 

associating said model with a predefined 
infrastructure model by populating, the infrastructure model 
with implementation data associated with said model so as 
to define an executable specific software application. 
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19. A coinputer program product coitprising conputer 
executable code for building software applications, the 
computer program including a model execution application 
implementing a meta-model that is adapted to be populated 

5 with user inputs to generate one or more models, the model 
execution application also including a predefined 
infrastructure model/ the program being adapted to: 

populate the meta-model with data input by a user to 
generate a model; and, 
10 associate said model with the predefined 

infrastructure model by populating the. infrastructure model 
with implementation data associated with said model input 
by a user so as to define an executable specific software 
application. 

15 

20. A computer irt^Jlemented method of executing a business 
domain model, the , business domain model modelling the 
semantics of the business domain and being defined in terms 
of a meta-model, the method comprising the step of 

20 associating the business domain model with an 
infrastructure model, the infrastructure mqdel being 
defined in terms of the meta-model, to define an executable 
specific software application, in which the infrastructure 
model is populated with inqplementation data associated with 

25 the business domain model. 

21. A method or computer program product according to any 
of claims 18 to 20, in which the infrastructure model is 
defined in terms of the same meta-model. 

30 

22. A method or computer program product according to any 
of claims 18 to 21, in which the meta-model is structured 
as a number of concepts, each concept having a number of 
properties, and one or more relationship? between the 

35 properties of one or more of the concepts, wherein the 
relationships are defined as a concept within the meta- 
model. 
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23. A methcxi according to claims 18 or 20, in which the 
meta-model is used to define a business domain model that 
represents a business or a part thereof. 

,5 24. A method of modelling a business domain conprising 
the steps of: 

dividing . the business domain into a number o£ core 
concepts, each core. concept having a number of properties 
and representing a self contained function of the business 
. 10 domain; . 

determining the relationships between the core 
concepts; and, 

populating a meta-model with data representing the 
core concepts and the relationships there between to 
15 thereby model the business domain - 
25. A method according to claim 24, in which the meta- 
model is structured as a number of concepts, each concept 
having a number of properties, cuid one or more 
20 relationships between the properties of one or more of the 
concepts, wherein the relationships are defj^ued as a 
concept within the meta-model. 

26. A method according to claim 24 or 25, in which the 
25 business domain model is defined by: 

dividing the business domain into a number of core 
concepts, each core concept having a number of properties 
and representing a self contained function of the business 
domain; 

30 determining the relationships between the core 

concepts; and, 

populating the meta-model with concept data 
representing the core concepts and the relationships there 
between. 

35 

27. A computer program product comprising computer 
generated code mirroring a business domain, the computer 
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program product including a business domain model which 
models the semantics of the business domain, and an 
infrastructure model which models the infrastructure of the 
business domain, wherein the business domain and 
infrastructure models are defined in terms of a meta-itradel, 
the metarmodel comprising a number of concepts, each 
concept having a nximber of properties, cuid one . or more 
relationships between the properties of one or more of the 
concepts, wherein the relationships are defined as a 
concept within the meta-model • 

28. A coit5>uter program product comprising conputer 
executable code for defining a model, the computer program 
implementing a meta-model which, when populated with user 
input data, defines the model, the meta-model comprising: 

a number of concepts, each concept having a number of 
properties; and, 

one or more relationships between the properties of 
one or more of the concepts/ 

wherein the relationships are defined as a concept 
within the meta-model such that the m^ta-model. can be 
described in terms of the concepts and relationships 
defined therein. 

29. A computer program product according to claim 28, the 
computer program product being adapted to define a business 
model, the business model con^rising: 

an infrastructure model which models the business 
infrastructure; and, 

a business domain model which models the semantics of 
the business. 

wherein the business domain and infrastructure models . 
are defined in terms of a meta-model. 
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ABSTRACT 

A UNIVERSAL SOFTWARE APPLICATION 

In the present invention, a conqputer program product 
5 comprises computer executable code for building software 
applications, the conqputer program including a model 
execution applicatidn inplemetiting a met a -model (1) which 
is adapted to be populated with user inputs to generate one 
or more models (3,6-9). The model execution application 

10 also includes a predefined infrastructure model (5) • The 
program is adapted to populate the meta-model (1) with data 
(19) input by a user to generate a model (13) and 
subsequently associate said model (3) with the predefined 
infrastructure model (5) by populating the infrastructure 

15 model with inplementation data (15) associated with said 
model so as to defirie an executable specific software 
application. In the preferred embodiment, the 

infrastructure model (5) is defined in terms of the same 
meta-model (1) . The meta-model (1) is preferctbly 

20 structured as a number of concepts, each concept having a 
number of properties, and one or more relationships between 
the properties of one or more of the concepts, in which the 
relationships are defined as a concept within the meta- 
model (1) . 

25 

[Figure 1] 
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